Great PR! Please pay attention to the following items before merging:

Files matching lib/**.pm:

• Consider adding or extending unit tests in t/

This is an automatically generated QA checklist based on modified files.

Why do we need YAML support in XFSTESTS_BLACKLIST? We already have XFSTESTS_KNOWN_ISSUES. Can we use it? I check our jobs and I see:

• maintenance https://openqa.suse.de/tests/21415724#settings: there is XFSTESTS_KNOWN_ISSUES and there is no blacklist
• development https://openqa.suse.de/tests/21340875#settings: there is XFSTESTS_BLACKLIST and there are no known issues

Can we use just one variable ? Bot variables points into same repo anyway (just different files for different product).

Why do we need YAML support in XFSTESTS_BLACKLIST? We already have XFSTESTS_KNOWN_ISSUES. Can we use it? I check our jobs and I see:

* maintenance https://openqa.suse.de/tests/21415724#settings: there is `XFSTESTS_KNOWN_ISSUES` and there is no blacklist

* development https://openqa.suse.de/tests/21340875#settings: there is `XFSTESTS_BLACKLIST` and there are no known issues

Can we use just one variable ? Bot variables points into same repo anyway (just different files for different product).

In a brief, we just extend original XFSTESTS_BLACKLIST to use a yaml file. That's for change history tracking, and more readable. This won't impact maintenance testing.
Beside that, we can shrink our existing yaml file with XFSTESTS_BLACKLIST format. (It can delete more than 10k lines.)
And it cannot use one variable as XFSTESTS_KNOWN_ISSUES used LTP::Whitelist.

More details in, #24639